There is a general need for implementing and utilizing device-specific security data in a wide variety of different devices such as mobile telephones, personal computers, cameras, audio devices, servers, base stations and firewalls. Device-specific security data can be used for various purposes, including management of security issues in relation to communication over insecure networks, content-marking of digital content and so forth.
To facilitate the understanding of a rationale behind the present invention, it may be helpful to think of the manufacturing process of devices in large volumes. In particular, it may for example be useful to consider a device manufacturer, with limited trust in any third party (in particular third party chip manufacturers), that needs to produce devices containing tamper-resistantly protected and per-device unique cryptographic keys and/or other security data to a low cost.
In network communication, for example, data security is often based on some sort of security data, e.g. a cryptographic key, which is used to establish data confidentiality, data integrity, authentication, authorization, non-repudiation and/or other security services. With the rapid development of Internet, packet data telecommunications networks and other communications networks, it has become increasingly more important to be able to provide proper data security such as protecting messages exchanged between nodes and/or devices in the network. For simplicity, any entity that participates in such communication will be referred to as a network device, and examples include mobile telephones, personal computers, security gateways, firewalls, radio base stations and so forth.
There are several difficulties in securely and cost efficiently manufacturing devices with security data that can later be used e.g. for security issues in connection with network communication:                To install or implement device-specific security data, different for each device. This may require entirely new manufacturing processes for some device components and thus become costly and/or inefficient.        To place the security data in a location within the device such that it cannot be compromised or manipulated by unauthorized parties.        To ensure that the security data is protected from unauthorized parties during the entire manufacturing process of the device. In particular if untrusted parties are involved during manufacturing, additional security management may be necessary.        To securely manage information, related to the security data, that is needed for an authorized party to later be able to provide data security in relation to device e.g. setting up a secure connection with the device. For example, if the device security data is a shared secret key in a cryptographic protocol, such as an authentication and/or encryption protocol, the same key must be available, and only available, for the authorized communications partner(s) that should be able to set up the secure connection with the device.        
For example, many communication systems of today, including mobile communication systems, paging systems, as well as wireless and wireline data networks, employ authentication and encryption procedures for the purpose of improving system security and robustness. The problem of establishing secure and robust communication is encountered in many technical applications, ranging from general network communication to more specific applications such as Digital Rights Management (DRM).
In general, there are two solutions for storing security data in a device, either on a chip or Integrated Circuit (IC) or in some sort of programmable memory, e.g. a PROM, keeping in mind that data stored on an IC is generally more protected.
In reference [1], a master key is stored in the EEPROM of a smart card, and used for encrypting sensitive information to be stored in a relatively less secure storage medium.
Reference [2] discloses a processor, which is connected to an external device for the purpose of downloading a program from the external device into its RAM memory. If the program is encrypted, a decryption module arranged in the processor accesses a key permanently stored in the processor in order to decrypt the program information.
Reference [3] mentions so-called on-board key generation in connection with smart cards.
Storing secret data, e.g. a device-specific random number, on an IC is possible today with standard IC production tools. However, the logistics for securely passing the random number or some related data from the IC manufacturer to the device manufacturer where the IC is used is with the present techniques either infeasible/expensive and/or requires special security management for handling the security data. In general, the device manufacturer and the IC manufacturer may be different parties. If some security data is managed by the IC manufacturer then this may be a security weakness, a possible target for attacks and may also increase the costs of the IC.
The same argument applies to the IC manufacturer generating and/or storing cryptographic keys on an IC on behalf of a device manufacturer.
The device manufacturer can let the IC manufacturer store, on the IC, data that is not possible to extract after IC manufacturing, unless very advanced reverse engineering is involved. However, using this device data in a security context with the help of state-of-the-art techniques requires security management in and between IC manufacturer and device manufacturer, and is either not secure or unfeasible/expensive in an industrialization process, in particular for a mass market.
The device manufacturer can insert security data into PROM thus avoiding to include the IC manufacturer as a trusted third party, and also avoiding costly changes in the IC manufacturing process. However, secrets in PROM are not as well protected against an adversary with access (even if it is just temporary) to the device. Moreover, the ASIC (Application Specific Integrated Circuit) technology required for realizing PROM functionality induces considerable extra costs on the IC, for example, through additional masks in the production process of the IC.
In addition, the IC manufacturer may want to limit the use of its ICs to those device manufacturers that he/she trusts or has business agreements with.
A somewhat different, but still related problem is for a third party, with trust relations to the device manufacturer and/or the user, to securely communicate with the device or with a user of the device. The security management of the device-specific security data may thus require including other parties as well.